Yes, it’s actually possible! – in Verilog and VHDL, even.

I’m a big fan of inference, especially as it applies to writing synthesizable Verilog code for FPGAs. Properly coded, a module that infers technology-dependent blocks (e.g. block RAMs) should: be portable between devices from a particular vendor (e.g. Spartan 3E to Virtex 6), be portable between devices from different vendors (e.g. Spartan 6 to Cyclone III), and even be portable to vendor-independent environments (e.g. simulation in Icarus Verilog).

The trick is that little “properly coded” clause. Figuring out exactly the right sort of Verilog required to get a particular tool to infer the block you want isn’t always straight-forward. Figuring out exactly the right sort of Verilog to get multiple tools to infer the block you want can be even trickier. Which is, perhaps, a little bit silly – considering that the whole point behind this little exercise is to be able to write code that isn’t tied to any particular tool, device or vendor!

Using current synthesis tools from Xilinx (ISE WebPack 12.2) and Altera (Quartus II Web Edition 10.0 SP1), it’s now practical to write synthesizable device and vendor-independent Verilog code (or VHDL, if that’s your thing) that properly infers true dual-port (TDP), dual-clock block RAMs in each vendor’s respective FPGAs. There are, of course, a variety of limitations and caveats that come along with that statement.

Limitations

After:

• reviewing each vendor’s pertinent documentation: the “RAMs Hardware Description Language (HDL) Coding Guidelines” from Xilinx’s XST User Guide for Virtex-6 and Spartan-6 Devices (the pre-6 XST guide doesn’t cover any of XST’s more advanced inference capabilities), and the “Inferring Memory Functions from HDL Code” section of Altera’s Recommended HDL Coding Styles;
• reviewing each vendor’s language templates: Edit->Language Templates in ISE’s GUI, followed by drilling down to {Verilog,VHDL}->Synthesis Constructs->Coding Examples->RAM->BlockRAM; and Edit->Insert Template in Quartus’ GUI, followed by {Verilog,VHDL,SystemVerilog}->Full Designs->RAMs and ROMs;
• and performing a few non-exhaustive synthesis experiments of my own,

..a few interesting differences can be found between Xilinx’s and Altera’s respective abilities to infer memories:

• Both Xilinx and Altera support inferring dual-port RAMs with mixed-width ports (e.g. Port A views a memory as 512×36, while Port B views the exact same memory as 1024×18). Xilinx supports this in VHDL and Verilog. Altera supports this in VHDL and SystemVerilog (but not plain Verilog). Unfortunately, neither uses constructs that the other can understand.
• Both Xilinx and Altera support inferring byte-enables, to a certain extent. Xilinx only supports byte-enables on single-port memories. Altera supports byte-enables on both simple and true dual-port memories. Again: Xilinx supports VHDL and Verilog, Altera supports VHDL and SystemVerilog, and both use mutually incompatible constructs.
• Xilinx has an additional quirk relating to inferring byte-enables. XST supports 2 different coding styles: one is newer, and recommended for Virtex-6/Spartan-6 series devices (but doesn’t work on older devices); the other is older and works on all devices (but doesn’t support inferring write-first behavior).
• Both Xilinx and Altera support specifying the initial contents of inferred RAMs and ROMs using Verilog initial blocks with $readmemh statements. Not a difference, but kinda neat (this will work in simulation, too).
• Xilinx supports inferring clock-enables on all BRAM types. Altera only seems to support this on simpler forms of memories. Trying to place clock-enables on a true dual-port memory yields the distinctly unhelpful message “RAM logic is uninferred due to asynchronous read logic”.
• Xilinx supports inferring all 3 read/write synchronization behaviors: write-first, read-first and no-change; or “new data” and “old data” read-during-write behavior in Altera parlance (Altera doesn’t explicitly call out a no-change analogue, but does support a read-enable signal that can achieve the same behavior). Altera seems to only support inferring write-first behavior on dual-clock RAMs, but they do support inferring both behaviors on single-clock true dual-port RAMs.

Anecdotally speaking, Xilinx’s tools seemed better able to cope with variations on coding styles than Altera’s, and had far more consistent behavior across different types of memories (e.g. clock-enables are always supported). Both Xilinx and Altera could really stand to work on arriving at inference templates that are actually interoperable.

Anyway. The end result of all that is a notion of what currently constitutes the least-common-denominator for features of an inferred true dual-port, dual clock RAM:

• Two ports, each with:
  • clock
  • address
  • write enable
  • write data
  • read data
• Write-first (“new data”) behavior
• No clock enables
• No byte enables
• No asymmetry (no mismatched port widths)

Verilog Implementation

Writing the Verilog to implement that subset in a parameterized fashion is trivial:

// A parameterized, inferable, true dual-port, dual-clock block RAM in Verilog.

module bram_tdp #(
    parameter DATA = 72,
    parameter ADDR = 10
) (
    // Port A
    input   wire                a_clk,
    input   wire                a_wr,
    input   wire    [ADDR-1:0]  a_addr,
    input   wire    [DATA-1:0]  a_din,
    output  reg     [DATA-1:0]  a_dout,
    
    // Port B
    input   wire                b_clk,
    input   wire                b_wr,
    input   wire    [ADDR-1:0]  b_addr,
    input   wire    [DATA-1:0]  b_din,
    output  reg     [DATA-1:0]  b_dout
);

// Shared memory
reg [DATA-1:0] mem [(2**ADDR)-1:0];

// Port A
always @(posedge a_clk) begin
    a_dout      <= mem[a_addr];
    if(a_wr) begin
        a_dout      <= a_din;
        mem[a_addr] <= a_din;
    end
end

// Port B
always @(posedge b_clk) begin
    b_dout      <= mem[b_addr];
    if(b_wr) begin
        b_dout      <= b_din;
        mem[b_addr] <= b_din;
    end
end

endmodule

VHDL Implementation

Likewise, in VHDL:

-- A parameterized, inferable, true dual-port, dual-clock block RAM in VHDL.

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity bram_tdp is
generic (
    DATA    : integer := 72;
    ADDR    : integer := 10
);
port (
    -- Port A
    a_clk   : in  std_logic;
    a_wr    : in  std_logic;
    a_addr  : in  std_logic_vector(ADDR-1 downto 0);
    a_din   : in  std_logic_vector(DATA-1 downto 0);
    a_dout  : out std_logic_vector(DATA-1 downto 0);
    
    -- Port B
    b_clk   : in  std_logic;
    b_wr    : in  std_logic;
    b_addr  : in  std_logic_vector(ADDR-1 downto 0);
    b_din   : in  std_logic_vector(DATA-1 downto 0);
    b_dout  : out std_logic_vector(DATA-1 downto 0)
);
end bram_tdp;

architecture rtl of bram_tdp is
    -- Shared memory
    type mem_type is array ( (2**ADDR)-1 downto 0 ) of std_logic_vector(DATA-1 downto 0);
    shared variable mem : mem_type;
begin

-- Port A
process(a_clk)
begin
    if(a_clk'event and a_clk='1') then
        if(a_wr='1') then
            mem(conv_integer(a_addr)) := a_din;
        end if;
        a_dout <= mem(conv_integer(a_addr));
    end if;
end process;

-- Port B
process(b_clk)
begin
    if(b_clk'event and b_clk='1') then
        if(b_wr='1') then
            mem(conv_integer(b_addr)) := b_din;
        end if;
        b_dout <= mem(conv_integer(b_addr));
    end if;
end process;

end rtl;

Synthesis

Running the Verilog code through XST yields:

Synthesizing (advanced) Unit <bram_tdp>.
INFO:Xst:3040 - The RAM <Mram_mem> will be implemented as a BLOCK RAM, absorbing the following register(s): <a_dout> <b_dout>
    -----------------------------------------------------------------------
    | ram_type           | Block                               |          |
    -----------------------------------------------------------------------
    | Port A                                                              |
    |     aspect ratio   | 1024-word x 72-bit                  |          |
    |     mode           | write-first                         |          |
    |     clkA           | connected to signal <a_clk>         | rise     |
    |     weA            | connected to signal <a_wr>          | high     |
    |     addrA          | connected to signal <a_addr>        |          |
    |     diA            | connected to signal <a_din>         |          |
    |     doA            | connected to signal <a_dout>        |          |
    -----------------------------------------------------------------------
    | optimization       | speed                               |          |
    -----------------------------------------------------------------------
    | Port B                                                              |
    |     aspect ratio   | 1024-word x 72-bit                  |          |
    |     mode           | write-first                         |          |
    |     clkB           | connected to signal <b_clk>         | rise     |
    |     weB            | connected to signal <b_wr>          | high     |
    |     addrB          | connected to signal <b_addr>        |          |
    |     diB            | connected to signal <b_din>         |          |
    |     doB            | connected to signal <b_dout>        |          |
    -----------------------------------------------------------------------
    | optimization       | speed                               |          |
    -----------------------------------------------------------------------
Unit <bram_tdp> synthesized (advanced).

And, through Quartus:

Warning: Inferred dual-clock RAM node "mem~0" from synchronous design logic.  The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
Info: Inferred 1 megafunctions from design logic
    Info: Inferred altsyncram megafunction from the following design logic: "mem~0" 
        Info: Parameter OPERATION_MODE set to BIDIR_DUAL_PORT
        Info: Parameter WIDTH_A set to 72
        Info: Parameter WIDTH_B set to 72
        Info: Parameter WIDTHAD_A set to 10
        Info: Parameter WIDTHAD_B set to 10
        Info: Parameter NUMWORDS_A set to 1024
        Info: Parameter NUMWORDS_B set to 1024
        Info: Parameter OUTDATA_REG_A set to UNREGISTERED
        Info: Parameter OUTDATA_REG_B set to UNREGISTERED
        Info: Parameter ADDRESS_REG_B set to CLOCK1
        Info: Parameter INDATA_REG_B set to CLOCK1
        Info: Parameter WRCONTROL_WRADDRESS_REG_B set to CLOCK1
        Info: Parameter INDATA_ACLR_A set to NONE
        Info: Parameter WRCONTROL_ACLR_A set to NONE
        Info: Parameter ADDRESS_ACLR_A set to NONE
        Info: Parameter ADDRESS_ACLR_B set to NONE
        Info: Parameter OUTDATA_ACLR_B set to NONE

Mission accomplished! – right? Not quite. Not unequivocally, anyway. There are yet more caveats..

Simulation mismatches

I hope you caught that little warning that Quartus issued. It brings up a very important caveat with respect to inferring RAMs: you must be very careful to avoid simulation/synthesis mismatches! For dual-clock memories, when one asynchronous clock domain attempts to write to the same address as the other clock domain is presently reading (or, worse: also writing), the behavior is typically unpredictable in both Xilinx and Altera FPGAs.

Have a look at this excerpt from the “Conflict Avoidance” section of Xilinx’s Spartan-6 Block RAM User Guide:

Asynchronous clocking is the more general case, where the active edges of both clocks do not occur simultaneously:

• There are no timing restrictions when both ports perform a read operation.
• When one port performs a write operation, the other port must not read- or write- access the same memory location. The simulation model will produce an error if this condition is violated. If this restriction is ignored, a read or write operation will produce unpredictable results. There is, however, no risk of physical damage to the device. If a read and write operation is performed, then the write will store valid data at the write location.
• In READ_FIRST mode only, the dual-port block RAM has the additional restriction that addresses for port A and B cannot collide. This applies for both TDP and SDP modes. A read/write on one port and a write operation from the other port at the same address is not allowed. This restriction on the operation of the block RAM should not be ignored.
  • RAMB16BWER when both ports are 18 bits wide or smaller: A13–A6, including A4, cannot be the same.
  • RAMB16BWER when any one port is 36 bits wide: A13–A7, including A5, cannot be the same.
  • RAMB8BWER in all configurations: A12–A6 including A4 cannot be the same.

Yeah. Really. A simplistic, idealized model can’t even begin to describe that sort of behavior. So, if there is any risk that your design may attempt to access the same (or similar) address simultaneously from two different clock-domains (with at least one of those accesses being a write), you’ll need to take extra precautions to ensure your simulations accurately verify the design’s behavior. Two possible options would be: attempting to upgrade the inferable model to include simulation checks for this behavior, or reverting to using manually-instantiated device primitives.

I wasn’t immediately able to find anything in Altera’s documentation that was quite as restrictive as Xilinx’s above notes about read-first address collisions, but I would not be surprised if Altera had similar restrictions. In any case, it’s still worth reading over the “Read-During-Write” section of Altera’s Internal Memory (RAM and ROM) User Guide, and the “Read-During-Write Operations” section of the handbook for a particular device family (e.g. the Memory Blocks in Cyclone III Devices document). For example, Altera specifies the undefined mixed-port read-during-write behavior thusly:

For mixed-port read-during-write operation with dual clocks, the relationship between the clocks determines the output behavior of the memory. If you use the same clock for the two clocks, the output is the old data from the address location. However, if you use different clocks, the output is unknown during the mixed-port read-during-write operation. This unknown value may be the old or new data at the address location, depending on whether the read happens before or after the write.

It’s interesting to note that Altera actually indicates that “the unknown value may be the old or new data at the address location,” rather than merely leaving it as unknown/invalid/unpredictable (as Xilinx does). Conceivably, this is behavior that might be useful in a real design (maybe not a good design, but a design nonetheless). Without more concrete assurances from Xilinx, however, you wouldn’t want to rely on this behavior.

Unsurprisingly, neither Xilinx nor Altera has defined behavior for simultaneous writes to the same address from two ports. Altera, for example, states this under “Conflict Resolution”:

When you are using M9K memory blocks in true dual-port mode, it is possible to attempt two write operations to the same memory location (address). Because there is no conflict resolution circuitry built into M9K memory blocks, this results in unknown data being written to that location. Therefore, you must implement conflict-resolution logic external to the M9K memory block.

Unexpected behavior

Mismatches aren’t limited to obscure corner-cases in simulation. Take this (seemingly) relatively-mundane simple dual-port memory, for example:

module relatively_mundane_sdp_ram #(
    parameter DATA = 72,
    parameter ADDR = 10
) (
    // Shared
    input   wire                clk,

    // Write Port
    input   wire                wr,
    input   wire    [ADDR-1:0]  wr_addr,
    input   wire    [DATA-1:0]  wr_data,

    // Read Port
    input   wire    [ADDR-1:0]  rd_addr,
    output  wire    [DATA-1:0]  rd_data
);

// Shared memory
reg [DATA-1:0] mem [(2**ADDR)-1:0];

// Write Port
always @(posedge clk)
    if(wr)
        mem[wr_addr] <= wr_data;

// Read Port
reg [ADDR-1:0] rd_addr_reg;
always @(posedge clk)
    rd_addr_reg <= rd_addr;

assign rd_data = mem[rd_addr_reg];

endmodule

The intent with that code is to create a memory in which writes will fall-through to the read port if the write and read addresses match. This would, for instance, be used in creating a low-latency synchronous FIFO with first-word-fall-through (FWFT); data pushed to an empty FIFO would be visible on the pop port on the following cycle. This exact behavior isn’t directly supported by Xilinx’s or Altera’s block RAMs.

Nonetheless, if you try to run this code through XST, it will happily infer a BRAM:

Synthesizing (advanced) Unit <relatively_mundane_sdp_ram>.
INFO:Xst:3040 - The RAM <Mram_mem> will be implemented as a BLOCK RAM, absorbing the following register(s): <rd_addr_reg>
    -----------------------------------------------------------------------
    | ram_type           | Block                               |          |
    -----------------------------------------------------------------------
    | Port A                                                              |
    |     aspect ratio   | 1024-word x 72-bit                  |          |
    |     mode           | write-first                         |          |
    |     clkA           | connected to signal <clk>           | rise     |
    |     weA            | connected to signal <wr>            | high     |
    |     addrA          | connected to signal <wr_addr>       |          |
    |     diA            | connected to signal <wr_data>       |          |
    -----------------------------------------------------------------------
    | optimization       | speed                               |          |
    -----------------------------------------------------------------------
    | Port B                                                              |
    |     aspect ratio   | 1024-word x 72-bit                  |          |
    |     mode           | write-first                         |          |
    |     clkB           | connected to signal <clk>           | rise     |
    |     addrB          | connected to signal <rd_addr>       |          |
    |     doB            | connected to signal <rd_data>       |          |
    -----------------------------------------------------------------------
    | optimization       | speed                               |          |
    -----------------------------------------------------------------------
Unit <relatively_mundane_sdp_ram> synthesized (advanced).

This won’t work! Again, an excerpt from Xilinx’s Block RAM User Guide (this time, from the “Synchronous Clocking” subsection of the “Conflict Avoidance” section):

When one port performs a write operation, the write operation succeeds; the other port can reliably read data from the same location if the write port is in READ_FIRST mode. DATA_OUT on both ports will then reflect the previously stored data.
If the write port is in either WRITE_FIRST or in NO_CHANGE mode, then the DATA_OUT on the read port would become invalid (unreliable). The mode setting of the read-port does not affect this operation.

Invalid won’t do. We want the read port’s data to reflect the newly written data from the write port!

To Altera’s credit, Quartus does correctly implement this behavior. Since it can’t be mapped directly to a RAM, Quartus adds additional bypass logic (using extra logic-elements in the process). It even tells you that it’s doing this:

Warning: Inferred RAM node "mem~0" from synchronous design logic.  Pass-through logic has been added to match the read-during-write behavior of the original design.
Info: Inferred 1 megafunctions from design logic
    Info: Inferred altsyncram megafunction from the following design logic: "mem~0" 
        Info: Parameter OPERATION_MODE set to DUAL_PORT
        Info: Parameter WIDTH_A set to 72
        Info: Parameter WIDTHAD_A set to 10
        Info: Parameter NUMWORDS_A set to 1024
        Info: Parameter WIDTH_B set to 72
        Info: Parameter WIDTHAD_B set to 10
        Info: Parameter NUMWORDS_B set to 1024
        Info: Parameter ADDRESS_ACLR_A set to NONE
        Info: Parameter OUTDATA_REG_B set to UNREGISTERED
        Info: Parameter ADDRESS_ACLR_B set to NONE
        Info: Parameter OUTDATA_ACLR_B set to NONE
        Info: Parameter ADDRESS_REG_B set to CLOCK0
        Info: Parameter INDATA_ACLR_A set to NONE
        Info: Parameter WRCONTROL_ACLR_A set to NONE

Conclusion

Well, now, that was easy! Certainly vastly simpler than manually instantiating device primitives – right?

So maybe inference isn’t an entirely ideal solution yet, but if you have a reasonably well-behaved design (one that doesn’t perform simultaneous reads and writes of identical memory locations) that doesn’t require anything too exotic (as if clock-enables could be considered exotic) and needs to be easily portable between vendors, then you might just give it a try. Otherwise, you may have to stick to your RAMB16s and ALTSYNCRAMs for a while longer.

A closing disclaimer: though the information presented here may appear authoritative and exhaustive (or, at least, exhausting), I must stress that these are merely my preliminary findings. It’s quite possible that I’ve overlooked or misinterpreted something (especially on the Altera side – I’m typically more of a Xilinx guy). I was focused on creating an inferable true dual-port, dual-clock memory, and did not run many tests of other forms of RAMs. When in doubt, try it out yourself!